Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

When Should an Analyst Suggest Using Queues in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:43:00 GMT

One of the most underrated skills for a business or system analyst in integration projects is knowing when to recommend a message queue — tools like RabbitMQ, Kafka, or Azure Service Bus.

Let’s be honest: not every integration needs one. But when it does, queues can save your system from chaos.

What Queues Actually Solve

Message queues are not just “another tech buzzword.”
They handle asynchronous communication — meaning systems don’t have to wait for each other to respond.

Example:
Instead of sending an invoice from System A and waiting for System B to confirm,
System A drops the invoice into a queue.
System B picks it up when it’s ready.

Benefits:

Smooth data flow even if one system is slow or offline
Built-in retry and error handling
Better scalability — handle thousands of messages per second
Natural decoupling between systems (less spaghetti logic)

When Analysts Should Recommend Queues
You don’t need a queue for every integration. But consider it when you see these signs:

High volume of transactions — more than a few thousand per hour.
Unstable or external systems — APIs that sometimes fail or have latency issues.
Different processing speeds — one system sends faster than another can receive.
Business-critical data — where you can’t risk data loss or duplication.
Complex workflows — where multiple consumers (systems) need the same event.

When Not to Use Queues

For real-time user interactions (e.g., “show me the balance now”) — queues add delay.
For simple 1:1 synchronous API calls — direct REST is cleaner and faster.
When the team can’t support monitoring (queues need visibility and alerts).

As an analyst, you don’t have to design Kafka topics or RabbitMQ exchanges.
But you should recognize the moment when a queue turns from “technical detail” into a business enabler — ensuring reliability, scalability, and peace of mind for everyone involved.

For Business/System Analysts who work with ERP integrations.

Andrii Siryi — Tue, 28 Oct 2025 15:42:00 GMT

When designing ERP integrations (for AR/AP document flows), Business/System Analysts often face a range of “gotcha” questions — technical, architectural, and sometimes unexpected.
Here are some of the real-world questions I ask clients during the API and ERP connector discovery phase:

What’s the minimum required ERP version to support all AR/AP endpoints?
Could upgrading the ERP version change the API behavior (fields, formats)?
Are there any heavy or slow API methods under load? Recommended workarounds?
Does the ERP provider charge for API calls, or is usage unlimited?
Can we get a list of possible API error codes?
Any record count limits per request? (e.g., max 1000 records in GET)
What type of authentication is used — Basic Auth, OAuth2, or token-based?
What’s the average response time of the API?
Are there any debug/logging tools if something goes wrong with the call?
Any breaking changes in recent patches that could affect us?
Does the API support batch insert/update or only record-by-record?
In what format are dates returned? Full datetime or date-only?
How are balances returned (positive/negative for credit memos)?
Can documents be posted without updating the "last modified" date?
Can an account include multiple subsidiaries? How to filter by them in the API?
Are any API methods planned for deprecation? What will replace them?
Are some API endpoints available only with paid ERP modules or add-ons?
Are some fields or features hidden unless specific ERP configuration settings are enabled?
Does the ERP API return full relational data (e.g., linked documents, GL splits), or do we need extra queries?
How can we detect deleted records if the API doesn’t expose a deleted flag or status?

These questions aren't just technical — they help avoid costly mistakes, failed syncs, or misunderstood logic.

Field Mapping vs. Canonical Data Model — Which One Wins in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:39:00 GMT

When building integrations between systems, one of the first architectural choices you’ll face is how to align data between them.
Two main approaches dominate this conversation: direct field mapping and the canonical data model.
Let’s break them down.

Field Mapping: Simple but Fragile

Field mapping means you connect each field from System A directly to a matching field in System B.
It’s fast to implement and easy to visualize:

Example:
“CustomerName” → “ClientFullName”
“InvoiceDate” → “BillingDate”

Pros:

Quick setup for simple integrations
Easier to debug and understand
Great for 1-to-1 integrations

Cons:

Every new system adds complexity — you end up maintaining dozens of mappings
Any field name or format change breaks the flow
Hard to scale beyond a few connections

This approach is fine for small, stable environments — like syncing data between CRM and ERP once a day.

Canonical Data Model: Structured and Scalable

A canonical model introduces a shared, unified data layer — a kind of “translation dictionary” for your enterprise.
Instead of connecting systems directly, each system maps to the canonical schema.

Example:
System A → Canonical Model → System B
“CustomerName” → “Customer.FullName” → “ClientFullName”

Pros:

Greatly simplifies multi-system integrations
Reduces maintenance costs over time
Makes it easier to add or replace systems

Cons:

Requires more design work upfront
May be overkill for small projects
Needs governance and version control

This approach shines in large ecosystems — where data flows across multiple ERPs, CRMs, or custom apps.

So… Which One to Choose?

If you’re connecting two systems and don’t expect frequent schema changes — use field mapping.
But if your integration landscape is growing and you want to reduce long-term pain — invest in a canonical model early.

Think of field mapping as a shortcut, and the canonical model as a foundation.

YAML-Based Story Mapping

Andrii Siryi — Tue, 28 Oct 2025 15:37:00 GMT

System Analysts who work with integration processes should formulate user stories in a way that diverges from the traditional structure. This is primarily due to the need for a more technical and structured description, which allows for the inclusion of integration-specific details.

The user story might need to specify exactly what kind of data should be retrieved via an API, from which system, using what HTTP method, and so on.
Additionally, such user stories can incorporate validation requirements.
For instance, before sending the data to an external system through an API, certain transformations or formatting might be required.

As a result, the structure of a user story in this context tends to differ significantly.

Here’s an example of how a story might look:

story_map:
epic: "Invoice Integration"

user_stories:

id: US001
title: "Obtain AR invoice"
as_a: "Application X"
i_want: "obtain AR invoices from ERP {{X}} via API"
so_that: "I can handle this invoice and send to the client"
source_system: "ERP {{X}}"
target_system: "Application X"
direction: "pull"
api_call:
method: "GET"
endpoint: "/api/invoices"
auth_required: true
id: US002
title: "Validate data"
as_a: "Application X"
i_want: "validate the fields of the received invoice"
so_that: "I don't sync the invoice with errors"
validation:
invoice_number: "required"
invoice_id: "required"
invoice_total_amount: "should be > 0"
invoice_status: "should be 'posted'"
id: US003
title: "Push invoice payment"
as_a: "Application X"
i_want: "push the invoice payment created in Application X to the ERP"
so_that: "the payment is approved in the ERP and synchronized back"
source_system: "Application X"
target_system: "ERP {{X}}"
direction: "push"
api_call:
method: "POST"
endpoint: "/api/payments"
auth_required: true

Execute your BPMN Diagram

Anthony Horner — Thu, 04 Feb 2021 06:01:00 GMT

BPMN 2.0 is a modelling standard that has been around for 10 years now and although it has its foibles it has been recognised as the best for capturing the business logic behind real-life scenarios. What most people don’t realise is that the standard itself is supported by an XML definition of its objects.

What does this mean? Essentially that the diagrams can be understood by computers to create an automated workflow application by any vendor’s product that is BPMN 2.0 compliant (and there are many). This means that users can log into their BPM application and have a task-list of assigned tasks to work that exactly replicate the business logic of the diagram. Think about that for a second, your BPMN diagram is converted into a workflow exactly as you designed it. That has huge consequences for amongst others, the software vendor industry. Why would you make a big ticket purchase to then have to configure and customise the processes that are implemented and still not match what you wanted from your diagram?

To show you an example, I’ve spun up an EC2 instance on AWS and have a version of Camunda’s open source BPM platform installed from a docker. This will allow you to see a BPMN diagram that has been deployed to a platform and actually execute it. In this case, a diagram to process expense receipts.

Camunda Tasklist (ec2-35-178-202-213.eu-west-2.compute.amazonaws.com)

Log into the app using the user/password demo/demo

The BPM platform can execute any valid BPMN diagram that it has deployed onto it. Each time, you launch an instance of the diagram, a workflow is created that will follow the logic exactly as described in the diagram. Each instance of the diagram also generates a mass of real-time data which can set-up all sorts of alerts (a subject for another article). If the process needs to change because of a change in market conditions etc. then an updated process is deployed onto the engine and the new process is live.

The comparison with the normal software development life-cycle is immense in terms of time and cost. Instead of using a BPMN diagram for context in a project initiation document kicking off an 18-month project, it could be the solution itself.

Admittedly, there is more to this, the front-end displayed to the users is usually developed to match company branding etc., the configuration of the platform with existing infrastructure takes time. Once this is done, the platform is highly scalable and as many different process models can be deployed to it as can be modelled.

A more detailed post can be found explaining this example on my website here

CEO and 160 employees skydive to launch a new corporate name in the sky!

BPM_online — Wed, 16 Oct 2019 16:06:00 GMT

Bpm'online, a global business software company leading in the space of low-code, process automation, and CRM, will be soon announcing their new company name. The new name will be launched in the sky via a breathtaking skydiving performance involving 160 bpm’online employees, including the CEO. The new name of bpm’online is to be formally announced on October 30th of this year during their renaming event, with the spectacular skydiving stunt, which highlights the importance and enthusiasm the company devotes to this occasion

Bpm’online is holding a large renaming event on October 30th. Registration for the event is open to anyone interested, and can be attended online. The renaming celebration event will display the launching of bpm’online’s new name in the sky with captivating skydiving footage.

“We wanted our renaming announcement to be truly one of a kind. While brainstorming for a creative way to reveal our new name, we came up with the idea of launching it in the sky. The whole team loved the idea so much that we accepted it immediately,” CEO and managing partner at bpm’online, Katherine Kostereva states. “We were expecting a couple of employees to want to skydive, but were happily surprised to find out that over 160 of our own staff were eager to participate. I was so inspired that I joined in too!”

Over 160 bpm’online employees from multiple countries volunteered to help launch the name by jumping out of a plane and taking the new name into the sky with them. For the majority of the team, including the CEO, this is their first skydiving experience ever. Professional skydivers will join them for the big day, while the rest of the company is enthusiastic to celebrate.

The Case Against Process Mapping and Why You Should Do Process Discovery Instead

Simona from Minit — Mon, 06 Aug 2018 08:44:00 GMT

Process mapping vs. process discovery is akin to perceived reality vs. reality; the former rooted in subjectivity, the latter rooted in verifiable data. Elements of process mapping creep into process discovery, restricting an absolute dichotomy between the two. However, the critical differentiator between mapping and discovery lies in the distinction between fact and fiction. Process discovery is primarily concerned with concrete, verifiable data (event logs, digital footprints), while process mapping relies on subjective first-hand remembered events.

Let us first review the core definitions of process mapping and process discovery before moving to the case against process mapping in favor of process discovery.

Key Differences Between Process Mappingig and Process Discovery

Process mapping is the human-side of establishing an ‘as-is-process.’ It’s concerned with measuring and comparing a defined objective against an organization's larger vision to ensure process are aligned with a company’s core competencies, capabilities, and overarching values. While the end game aims for process improvement, a significant element of subjectivity and unintentional validation techniques are laced within manual process mapping. Perceived reality is flawed regardless of intentions.

Automated process discovery, on the other hand, is exclusively concerned with verifiable data logs, providing an accurate picture of how processes are performed, rather than the idealized model of how they should be performed, or how employees think they are performed. Additionally, process discovery takes the white space between information systems and seemingly unrelated events and builds bridges with data rather than assumptions. Anomalies and outliers are accurately weighted without being unfairly amplified or ignored

Process Mapping	Process Discovery
Manual	Automated
Subjective	Objective
Remembered events	Verifiable event logs
Human validation	Data-driven
Limited scalability	Full scalability
Process details must be known by employees	No employee knowledge of process details needed
Slow, drawn-out	Fast, continuous
Too much or too little detail	Exact reality
White space between IT systems and processes unknown	White space between IT systems and processes bridged
Outliers ignored	Outliers appropriately weighted

Process Discovery vs Process Mapping — Why Discovery is Best

The case for process discovery is strong, particularly when midsize and enterprise level companies are looking to initiate Business Process Improvements (BPI). From knowledge gaps bridged to socio-cultural subjectivity eliminated, here are the top reasons to choose process discovery over process mapping.

1. You don’t know what you don’t know (white space)

White space is the unseen area between various systems, departments, and functions at the edges of a process. One of the most significant challenges in manual process mapping is effectively extracting information from employees involved in a process. Piecing together “remembered activities” to create a process map will inevitably be riddled with knowledge gaps, employee validation, and human subjectivity. In other words, you don’t know what you don’t know, and “unseen” events will not be included in the map.

Process discovery captures all the nuances of a process, including statistical information, process exceptions, unusual transactions, deviations, potential process risks, bottlenecks, and variants. Process discovery bridges the gaps between the individual process steps across multiple ERP and IT systems. Automated process discovery delivers a detailed process map rich with data and flexible for interactive analysis.

2. Map unstructured data from process unknown to employees

Concerning white space and knowledge gaps, some processes, and steps in a process are entirely unknown to employees and, therefore, must rely on digital event logs to create a picture of a process. Consider a global supply chain operating on Just-In-Time manufacturing principles. This fast-moving, lean approach to production relies on multiple actions triggered by a single event. Building on verifiable, time-stamped data logs from hundreds to hundreds of thousands of tiny events is something humans simply cannot map. Process discovery systems, like Minit, take this unstructured data and automatically create a process model to enable in-depth analysis. Minit technology is able to take various data inputs from scratch and deliver pattern recognition. This enables companies to discover processes without prior process knowledge or specifying an existing model.

3. Eliminate socio-cultural behavior from analysis

Humans make decisions based on emotions. It’s a fact wired into our neurological pathways. This doesn’t mean we are illogical, far from it. It means we gather information, process this information from our lens of reality, and then use the frontal lobe of our brain to make a decision — the area responsible for emotional expression, problem-solving, memory, language, and judgment.

Without intent for sabotage, humans will deliver a subjective view of reality, as well as use unintentional validation techniques. It’s not lying; it’s how we communicate as humans. Automated process discovery reads between the lines of data logs, not words, eliminating the presence of socio-cultural behavior from a process analysis. Additionally, what manual process mapping may express as statistical noise, process discovery can appropriately highlight as inefficiencies in business processes.

4. Focus on accuracy and speed

Have you ever seen a whiteboard overloaded with sticky notes — diamonds, arrows, mini-sticky notes upon larger sticky notes? An array of orange, pink, blue and green activities? This is process mapping. Process mapping can, and should, be accompanied by technology like Microsoft Visio and purpose-built process mapping tools, but keep in mind that these tools help you take sticky notes off a white board and build sticky notes on a computer screen. Your big win here is that a humid day won’t wipe progress off the board. This approach is still relying on human inputs, not data inputs, bringing accuracy level to a low.

In terms of speed, calculate the total human hours needed for individual staff interviews, facilitated discovery workshops, analysis of existing documentation and direct work observation. Then compare this to process mining software that plugs in, transforms unstructured data into meaningful maps, and delivers a flexible, in-depth process analysis based on hard data. This is an essential part of understanding the real cost of going through a BPI transformation.

5. Unlimited scalability

Last but not least, a massive benefit of automated process discovery over manual process mapping is scalability. Once systems are connected and process mining software established, a process can be endlessly reanalyzed with little to no additional effort. As subtle changes in the process are made during the discovery period, technology will capture this immediately and include it in data mapping. Businesses need to optimize business processes continuously, and scalability is a big part of making this financially feasible.

See Process Discovery Technology in Action

Minit software analyzes concrete data from various systems to discover how business processes flow in reality. Our platform automatically recreates process maps from traces of user actions (electronic footprints) left within applications. It provides an accurate picture of how users — employees, suppliers, customers, etc. — are performing their duties or actions rather than the idealized model of what they are supposed to be doing.

We’d love to show you the power of Minit and how it can help deliver an effective BPI transformation at your organization. Get in touch with our team to learn more and request a trial of Minit.

What is Pega Process Managment?

SarikaA — Mon, 29 May 2017 08:50:00 GMT

Pega systems(Software Company) is the leading provider of business process management (BPM) and customer relationship management (CRM) software solutions. Pega systems motto is “Build For Change” and their goal is to “eliminate software coding” and “automate manual work”.

Pega systems has been at the forefront of rules-based business automation systems since the early 1980s, a natural outgrowth of our founder’s pioneering work in computerized chess play. In recent years, as more and more businesses have concluded that business process management suites are a “must-have” technology, our BPM business has grown at twice the rate of the overall BPM market. At the same time, major analysts like Forrester and Gartner have consistently rated Pega systems as the leader in the dynamic BPM sector.

Pegasystems knows that what it all comes down to is delivering real-world business benefits, efficiently and quickly:

More so than any other process management suite, Pega BPM puts business users in control of process design and creation, while automating most of the code development and minimizing reliance on technologists.

Pega BPM patented inheritance technology enables a multi-layered process model in which a base of enterprise-wide rules and procedures are dynamically merged with an overlay of context-specific refinements suitable to particular regions, product lines, channels, or customers. This model enables you to capture in your BPM services a real-world reflecting mix of the universal and the particular.

To speed your time-to-benefits, Pega BPM offers a full range of industry-specific solution frameworks, based on best practices in financial services, insurance, health care, telecommunications, government, and others. For business process outsourcers, we also offer tailored BPO software and BPO solutions.

The perfect platform for enterprise-scale business performance management or business process integration initiatives as well as for more narrowly targeted pilot programs, the Pega business process management suite empowers business users, accommodates real-world variety, and pays rapid dividends.

End-to-End Business Process Management Services

Pegasystems delivers expert business process management services to support all phases and facets of your BPM project:

-Design review — Pegasystems’ business process management services team can help you get your BPM project off on the right foot with a thorough review of your application design. Working side-by-side with your project team and leveraging best-practice design principles, Pega BPM services staff will provide valuable feedback on both your design and your design process.

-Usability review — No matter how well-designed an application is internally, and no matter how powerful the underlying business process management system, the application won’t live up to its potential if your user interfaces are not meeting the needs of end users. The Pega business process management services team will review your UIs from the user perspective and help you identify ways to improve the user experience and increase user productivity.

-Transition readiness — Before you launch, Pega business process management services professionals will help you test your application, tune it, and prepare it for deployment. We’ll also work with you to assess your organization’s readiness to utilize the application.

-Performance check-up — Once your BPM application has been up and running for six months to a year, Pega professional services can evaluate your application’s performance to see whether you’re getting your maximum possible return. Detailed analysis and feedback from Pega business process management services -personnel can help you to fine tune your application and to optimize future applications as well.

-BPM methodology coaching — Pegasystems veteran BPM experts can coach your team on all the nuances of implementing an iterative and agile BPM methodology that best leverages the robust capabilities of your Pega BPM platform.

-Centers of excellence creation — Many leading companies are creating BPM-focused Centers of Excellence to drive BPM implementations across the enterprise. Pega professional services can help you with all aspects of launching a BPM Center of Excellence, including strategy development, infrastructure creation, and building of a BPM knowledge base.

A view of Business Architecture

Richard Skidmore — Sun, 10 Mar 2013 07:11:00 GMT

Just to pass some time recently, I was reading a dictionary (like you do) and I came across the following definitions of architecture:

The art and science of designing and superintending the erection of buildings and similar structures
A style of building or structure
Buildings or structures collectively
The structure or design of anything

So, I got to thinking about these, particularly the last one, and came to the following conclusion - you would not be a very good architect if you didn't understand how buildings are structured and how builders work.

So it seems sensible to conclude that you wouldn't be very useful as an architect in the world of:

data architecture, if you didn't understand data modelling and databases
applications architecture, if you didn't understand software construction and integration
infrastructure architecture, if you didn't understand technology and communications

Therefore, it must be a fundamental requirement for a Business Architect to understand business and the jigsaw of elements that need to fit together to make the entire picture. If I want to understand the business architecture, I need to appreciate the business motivations, business models and business capabilities, plus the people and processes that bind all these individual elements together to deliver value to customers and other stakeholders.

While any business architecture needs to be consistent with, and coordinated with, technical architectures, it is important to understand that it is a different type of architecture. It has clear requirements when it is being constructed. And, it requires a unique blend of skills and competencies to develop it. Business architecture is not just an afterthought of the technical and solution architecture world.

Many business analysts and business managers are becoming involved in business architecture. In developing their knowledge and skills, it is important that the focus is on business understanding if they are to understand the underlying concepts, interconnections and impacts needed for this rapidly expanding discipline to succeed.

In our current world, the pace of change in technology is significant. However, it is also true that with the advent of innovative ways of working, new ways of structuring organisations, streamlined processes and a work force with different motivations and aspirations, we need to consider the architectural considerations and aspirations of the business in addition to those related to the technology. This way, outcomes of real value can be achieved with minimum, or at the very least, controlled, impact to our organisations. It really is the only sustainable way forward.

More blogs can be found here...

Is Traceability Possible Without a Requirements Tool?

Seilevel — Mon, 20 Dec 2010 05:07:00 GMT

I have spent the last year and a half working on an enterprise software solution development effort where we do not use a Requirements Management tool like Caliber or Visual Studio TFS. Our requirements are created in Word using standardized templates and distributed to Development and Test teams for consumption.

Test cases are written in Excel and tied to the requirements in the documents. In general, I would have to say that coverage is good but not complete (I know this anecdotally since there is no good way using Excel and a bunch of Word documents to know for certain). In theory, a failed test case should mean that a requirement is not satisfied and pinpoints a missed feature or requirement.

This system breaks down totally when it comes to Change Requests that are created during the course of the project. Change Requests are entered directly into a defect tracking system. Change Requests are usually supposed to have detailed requirements associated with them but in practice the quality of the supporting documentation has varied widely. So, Change Requests have little to no systematic traceability associated with them. This is not to imply that the Change Requests are poorly implemented. Just that doing any kind of systematic tracing exercise against them is near impossible.

The key problems I have found with using Excel to perform traceability are as follows.

1. Forward traceability from Business Objectives or High Level Features to specific requirements is very difficult to do and in many cases is just not practical.
2. Managing requirements as they change is very difficult to do. You could have false positives where the spreadsheet tells you there is good coverage without realizing that the underlying requirement itself has changed.
3. Managing multiple tests for a single requirement because very difficult. For example, if a single requirement has to pass 3 test cases for it to be considered fully implemented, the spreadsheet approach becomes error prone and hard to understand very quickly.
4. The spreadsheets themselves become unwieldy as multiple requirements and tests are entered. The volume of data becomes hard to manage and consume.
5. Reporting becomes a hit and miss process. It requires a lot of manual effort, is time consuming and error prone.
6. Requirements that do not start life in a requirements document (Change Requests) are seldom tracked as rigorously as standard requirements.
7. Historical analysis is very difficult to do. On projects that last several years, digging up an old Excel spreadsheet to determine if specific requirements were implemented or not a year ago can easily become a week long exercise in futility.

So what then is the answer to the question I posed at the beginning?

Excel is fine for small projects but larger enterprise grade efforts require a specialized requirements tool with good tracing features.

The odds of performing good traceability on your project are significantly improved when using a requirements management tool. There are real costs associated with unimplemented or improperly implemented requirements. A good tool gives you a better chance of catching these kinds of errors with good traceability features. So, when considering a tool to manage your requirements, do not overlook the quality of their traceability features.

For more check out our blog: http://requirements.seilevel.com/blog/

By Abadri

Business Process Analysis (BPA) for the Masses -- Is It Real?

Derek Weeks — Fri, 03 Sep 2010 16:55:00 GMT

This Summer, Gartner produced a research paper entitled "BPA for the Masses: Is it Real?". The paper discusses the increasing popularity of business process modeling tools that can be used by business people. Gartner's position is that the business people have the greatest understanding of their process and can now be equipped with tools that enable them to produce process models very quickly.

Rather than shutting the business users out of the process modeling exercise, they can now be engaged from the beginning. Gartner comments that involving business people in the process modeling exercise helped support the business analyst's efforts to help business and IT understand the process and its related analysis better.

I found the paper interesting and wanted to know if others agreed. Should we place a business process analysis (BPA) tool in the hands of a business user?

When I asked some of my industry peers, I received the following response from Dan Darnell at Waltman, Weinberg & Reis:

“I designed and taught BPMN training focused on our ‘business people’ at QualChoice a few years ago. In my experience, non-IT, non-Analyst folk adapted well and ‘got’ the concepts. I don't understand why it should be surprising or unusual for business-side people to understand and use BPMN or, in general, BPM.

The business side should, or MUST, be involved in the process modeling exercise. Their involvement provides great benefit, and they should be given tools to document their processes themselves. IT, PMO, or similar organizations should not set themselves up as the exclusive provider of formal modeling work - it is not in the company's best interest. My experience was that the business side can model their own processes, and with the proper tools, their work can be integrated into the corporate model.”

Would you agree? Does giving a BPA tool to a business person help you? What has been your experience?

Additionally, Gartner recommends that companies avoid an initial step of buying a BPM suite or an expensive BPA tool. As they see more and more adoption of business process modeling as a responsibility of the business unit or a business service group, they see more businesses investing in low-cost, business-oriented, more accessible modeling tools. They provide many tool examples, but say that Visio clearly dominates.

Would you or have you put Visio in the hands of your business users?

Gartner states, “There are two primary reasons why BPA for the masses will become "real." One is the superior results in achieving true business performance improvement, and the other is the much-broader potential audience that can enable fuller collaboration.”

Do you see BPA for the Masses becoming real in your organization? I believe it only makes sense. The businesses know their process best, but have difficultly describing it or reaching consensus on the details…we have all seen this in discovery exercises. But, I believe there is great value in having business people collaborate with business and process analysts in building the process model while using a common tool. Involving the business helps improve their understanding of the process, their awareness of its complexity and potential problems, and their motivation to improve the process moving forward.

I’d like to hear what you think after you read the paper. For a free copy of the Gartner paper, go to: http://www.global360.com/download/bpa-report/

BPMN Library of processes?

Wed, 04 Nov 2009 16:38:00 GMT

In my time at programming I created or used any number of routines over and over again that did a specific job, from just a small function like adding a number of days to a date to writing out an error report or selecting data from an SQL database.

Now I'm a business analyst and there are many process modelling applications out there that follow a set standard (BPMN for example). I know there's more than one way to skin a cat, programming has taught me that, so what I'd like to know is why can't I find a library of process model routines that I can import into the BPMN application of choice and build up a simple library of my own to create processes faster?